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It  is  time  to  place  the  development  of  real-time  systems  on  a  firm  scientific  basis.  Unlike 
other  engineering  disciplines,  our  methods  arc  not  founded  on  science.  Real-time  systems  are 
built  one  way  or  another  because  that  was  the  way  the  "last  one”  was  built.  And,  since  the  "last 
one"  worked,  we  hope  that  the  next  one  will. 

True,  the  area  has  benefited  from  rigorous  mathematical  work  analyzing  various  scheduling 
policies  for  processors  and  other  shared  resources.  It  is  argued  that  managing  time  is  what  makes 
real-time  systems  different,  so  such  results  allow  us  to  put  the  discipline  on  a  firm  scientific  basis. 
While  I  certainly  agree  that  closed-form  analytical  equations  to  allow  task-response  time  predic¬ 
tions  under  various  assumptions  arc  useful,  the  existence  of  such  results  does  not  seem  to  move 
the  discipline  closer  to  a  science.  Why  is  this  the  case? 

The  view  that  we  should  add  a  "time  dimension"  to  all  of  what  computing  systems  research 
has  deemed  "good"  is  not  justified  and,  as  far  as  I  can  tell,  has  never  been  critically  examined.  It 
should  be.  Abstractions,  like  processes,  fairness,  and  finite  progress,  are  useful  in  connection 
with  concurrent  programs  and  operating  systems.  Because  they  are  abstractions,  they  suppress 
irrelevant  details  and  allow  us  to  concentrate  on  the  relevant  issues.  Relevance,  however,  is  in 
the  eye  of  the  beholder.  Processes,  fairness,  and  finite  progress  are  useful  in  writing  a  concurrent 
program  exactly  because  they  allow  us  to  ignore  details  of  process  interleavings  and  execution 
times.  In  real-time  systems,  however,  these  "details"  are  no  longer  irrelevant.  For  example,  the 

importance  of  execution  time  is  obvious  and  reasoning  about  process  interleavings  is  useful  in 

- 
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avoiding  priority  inversion.  Thus,  the  usual  abstractions  might  not  be  the  appropriate  starting 
point  for  real-time  programming. 

It  is  time  to  reconsider  our  abstractions  and  devise  some  that  are  better  suited  to  our  needs. 
Adding  semantic  Band-Aids  to  extant  abstractions  is  probably  not  the  best  way  to  devise  suitable 
abstractions.  Completely  ignoring  existing  abstractions  is  not  prudent,  cither.  The  new  abstrac¬ 
tions  should  build  on  and  generalize  the  old  ones.  Thus,  when  the  time  dimension  is  ignored,  the 
new  abstractions  should  degenerate  into  the  old  ones,  allowing  us  to  exploit  the  strengths  of  the 
old  ones  without  being  subject  to  their  weaknesses. 

Let  me  go  a  step  further.  Recently,  I  have  begun  to  question  an  implicit  belief  that  pervades 
the  field — that  time  is  fundamental  to  real-time  programs.  All  the  systems  with  which  I  am  fami¬ 
liar  can  be  modeled  as  a  collection  of  processes.  Some  of  the  processes  are  described  by  physical 
laws  and  can  only  be  controlled  indirectly  by  reading  and  writing  certain  variables  (sensors  and 
actuators).  Other  processes  are  described  by  program  code  that  has  been  designed  to  ensure  that 
the  entire  computation  continues  to  satisfy  some  constraints.  When  controlling  a  reactor,  we  are 
interested  in  its  temperature  and  pressure;  when  controlling  a  train,  we  are  interested  in  velocity 
as  a  function  of  track  position.  The  control  loop  for  these  applications  is 

do  true  — >  await  bad  state; 

perform  corrective  action 
od 

and  contains  no  explicit  mention  of  time.  Time  is  one  method  for  implementing  "await  bad 
state"  when  we  know  something  about  process  execution  speeds  and  the  rales  of  change  for  phy¬ 
sical  parameters.  But  observe  that  this  is  little  more  than  using  time  as  a  way  of  implementing 
synchronization  between  processes.  The  notion  of  "priority"  in  real-time  software  can  also  be 
seen  as  a  synchronization  method  for  asynchronous  processes,  although  it  is  rarely  described  in 
this  manner. 

I  have  hinted  at  a  new  paradigm  for  viewing  the  area:  synchronizing  asynchronous 
processes,  not  all  of  which  are  under  program  control.  Other  paradigms  should  also  be  investi¬ 
gated,  always  with  an  eye  towards  explaining  our  current  methods  and  problems  in  new  ways. 
Whether  or  not  the  new  paradigms  prove  useful,  the  problems  with  our  current  paradigm  remain. 
We  must,  therefore,  develop  appropriate  abstractions  for  our  current  paradigm  or  for  alternative 
paradigms. 

Associated  with  any  new  paradigm  for  programming,  we  would  expect  to  find  three  ele¬ 
ments; 

( 1 )  a  notation  for  specifying  requirements, 

(2)  a  notation  for  describing  computations,  and 

(3)  a  method  for  verifying  that  a  computation  satisfies  requirements. 

It  is  important  that  these  elements — specification,  description,  and  verification — all  be  addressed 
using  an  integrated  approach.  A  single  of  these  three  elements  can  make  sense  and  be  useful  only 
in  concert  with  the  other  two.  Moreover,  experience  in  sequential  programming  and  concurrent 


programming  has  shown  that  methods  f Wj  posteriori  verification,  as  required  by  (3),  can  lead  to 
program  development  calculi.  It  is  the  existence  of  such  calculi  that  will  put  the  field  on  a  firm 
scientific  basis. 
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